fix(tauri): restore notifications in remote windows - #641
Conversation
Mark remote CodeNomad webview windows explicitly as Tauri hosts so notification capability checks use the native plugin instead of the Web Notification API. Grant remote-* windows only the three notification commands used for permission checks, permission requests, and delivery across configured HTTP and HTTPS server origins. Keep native dialogs and other desktop privileges restricted to the main window. Add a regression assertion for the injected runtime context. Validated with the UI production build, UI typecheck, all 85 Tauri Rust tests, and independent capability/runtime reviews.
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper round 1: 4 findings.
- P2 security, packages/tauri-app/src-tauri/capabilities/remote-window-notifications.json:6: the capability accepts every HTTP(S) origin while the navigation guard currently treats every localhost/127.0.0.1 URL as internal. A remote-* window can therefore navigate away from its registered origin and retain app-branded notification access.
- P2 regression, packages/tauri-app/src-tauri/src/main.rs:50: marking remote windows as Tauri changes external URL handling. Provider OAuth now attempts the unauthorized native opener after the async authorization request, then falls back to window.open after user activation may have expired.
- P2 test gap, packages/tauri-app/src-tauri/src/main.rs:1098: the regression test covers the host marker only. Removing capability registration or required notification permissions still passes.
- P3 least privilege, packages/tauri-app/src-tauri/capabilities/remote-window-notifications.json:5: local is omitted and defaults to true for a capability intended only for externally hosted remote UI.
The claim that all custom app commands become available was reviewed but excluded: it is pre-existing and not a deterministic regression in this PR.
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper round 2: 2 findings.
- P3 UI consistency, packages/ui/src/lib/settings/behavior-registry.ts:305: remote Tauri windows now satisfy isTauriHost and display the native event transport toggle, but event-transport.ts always forces EventSource for remote windows. The control has no effect and must remain local-only.
- P2 test gap, packages/tauri-app/src-tauri/src/main.rs:1107: capability registration and permissions are asserted, but remote.urls is not. Narrowing or removing those patterns would restore the notification failure while tests pass.
Origin isolation, local=false, OAuth/browser fallback, Electron behavior and notification permissions otherwise have zero findings.
Pin remote webview HTTP and HTTPS navigation to each configured server origin before granting native notification IPC. Mark the capability remote-only and assert its exact URL, window, registration, and permission contract. Keep OAuth and external links on the browser popup path in remote Tauri windows, and hide the local-only native event transport setting there. This preserves existing remote behavior while identifying the physical host correctly for notifications. Validated with all 86 Tauri tests, UI typecheck and production build, rustfmt, diff checks, and three Gatekeeper rounds ending with zero findings.
…ications' into fix/issue-640-remote-tauri-notifications
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper round 4: 1 finding.
- P2 regression coverage, packages/ui/src/lib/external-url.ts:8, provider-manager-modal.tsx:188, behavior-registry.ts:305: the new remote-Tauri compatibility guards are not exercised by tests. Reverting them keeps all Rust/config tests green while breaking OAuth/external links or exposing a local-only setting.
No functional or security findings remain. Add one shared, pure local-Tauri predicate with explicit local/remote host-context tests, then run the final round.
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper round 5: 1 finding.
- P2 CI coverage, packages/ui/src/lib/runtime-env.test.ts:1 and .github/workflows/pr-build.yml:104: the new host-context regression test passes manually but is absent from the workflow's explicit UI test list, so future regressions would not fail PR checks.
No functional, security, runtime, or host-compatibility findings remain.
Centralize local-Tauri detection so native opener usage, OAuth popup behavior, and the native event transport setting share one host-context decision. Exercise local and remote Tauri plus web and Electron environments, and add the regression test to the PR workflow's explicit runnable UI suite. Validated with UI typecheck, production build, the exact 173-test workflow command, and Gatekeeper round 6 with zero findings.
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper round 6, final commit d846fcd: zero findings.
All findings from rounds 1-5 are resolved: remote origins are pinned, the notification capability is remote-only and least-privilege, OAuth/external links preserve browser behavior, local-only settings stay hidden remotely, capability contracts are asserted, and remote-Tauri guards run in PR CI.
Validation: 86/86 Rust tests, 173/173 runnable UI tests, UI typecheck, production UI build, rustfmt, and diff checks pass. Residual risk is limited to platform-specific WebView2/Windows notification integration; PR CI is currently restarting on the final commit.
|
@shantur LGTM |
Summary
Cause
Remote windows were marked with the remote window context but not with the Tauri runtime host. The UI therefore selected the Web Notification API inside WebView2, where requesting permission had no effect. Those windows also did not match a Tauri capability that allowed notification plugin commands.
Implementation
The initialization script now sets both runtime host and window context before remote UI scripts run. A dedicated capability permits only permission checks, permission requests, and notification delivery for configured HTTP/HTTPS remote origins.
Validation
Fixes #640